48_SPI Finalization
The physical SDI1 pin happens to be a remappable pin (RPI25 in Figure 1). Pin access priority is from left-to-right in the diagram, meaning that the PIC33’s ADC module as first priority on that pin. If the ADC functionality on pin 54 is enabled, it will disable any other module from using it. I disabled all analog systems for testing to make sure that AN28 on pin 54 was not preventing the SPI1 module from using it. SDI1 has the next priority, meaning that if the SPI1 system is enabled, pin 54 will be used as SD1 as long as AN28 is disabled. This eliminated the possibility of some other module remapping to RPI25 on pin 54, preventing the SPI module from using it. Also, RPI pins are only removable as inputs, and one input pin can be shared between modules. So even if another module was mapping to pin 54, it shouldn’t affect SPI1’s access to SDI1.
After checking the SPI1_init() function against online resources, I was not able to find anything causing the SDI1 pin to not receive data (also checked to make sure that pin was set to input functionality). The only remaining possibility was that I was mixing up the order in which the SPI_read() function should check for the SPIRBF bit. I couldn’t find anything wrong with the read function either, so I decided to try using the PIC33’s SPI2 module instead.
Figure 1: SDI1 Port On Remappable Pin 54
In the 100-pin TQFP dsPIC33 package, the SPI2 module does not exist by default on any of the physical pins. It has to be remapped to RPx and RPIx pins. I included the following code (Figure 2) in the SPI_init() function and modified all the program code to apply to the SPI2 module instead of the SPI1 module.
Figure 2: Remapping SPI2 to various pins on dsPIC33
After doing this and debugging minor problems with changing setup code from SPI1 to SPI2, the SDI2 pin seemed to be receiving information. Now the program was not getting stuck in the while loop waiting for the receive buffer bit to set. I confirmed that data was being received properly by checking a variable that was assigned to received value. When AIN0 on the ADC is plugged into 3.3V, the SDI2 should be receiving 0x7FFF. I used an if statement to turn on and off an LED if the received data equaled this, and it indicated that the correct data was being received. I also used this to check with a 0V conversion value, and it worked as well.
Next I had to set up configuration code for the ADC. For now, we probably need it to be in “continuous conversion” mode, so that it continues converting values after the START/SYNC (0x0008) command is sent
